1. Field of the Invention
The present invention relates to the design of asynchronous circuits. More specifically, the present invention relates to the design of arbiters with preferential enables for asynchronous circuits.
2. Related Art
Many computer systems have a router that controls traffic between a pool of servers and a queue of clients (see FIG. 1B). In a generic case, a client sends a request for service to the router and the router selects a server to provide the service.
Normally a router contains an arbiter (see FIG. 1A) which selects a server to service the next client request. An arbiter is a device that grants requests, one at a time, from any number of requesters. Although arbiters for three or more requestors exist, most arbiters are “binary arbiters,” which choose between two requesters. When there is only one request pending for a binary arbiter, the arbiter grants that request. When there are two requests pending, the arbiter makes a decision about which of two requests to grant first. In a typical system, after the arbiter grants a request, the environment eventually releases the grant by lowering the request input. The arbiter then acknowledges the release of the request by lowering the grant output. At this point, the arbiter may grant a subsequent request.
Designing reliable implementations of arbiters requires extra care, because such implementations can exhibit meta-stable behavior. Today, however, reliable circuit implementations of binary arbiters are well understood. Some circuit implementations of arbiters include cross-coupled NAND gates followed by some filter to delay the output until meta-stable behavior is over (see FIG. 1A).
Unfortunately, routing client requests to servers is not always this easy. Differing client requirements for servers can also create problems in designing a suitable hardware implementation for a router. Some clients can accept service from any available server, while other clients must be served by a particular server. In some systems, an arbiter may choose a server to service the next client request before the next client request has arrived. Such eager decisions may lead to an error, for example when the arbiter decides to send the next client request to server A, while that client requires service only from server B. An error can also occur when, upon arrival of a client request, both servers are available and the arbiter chooses a server that is different from the one preferred by the client.
Hence, what is needed is an arbiter that makes routing decisions which are consistent with requirements and/or preferences of clients.
Further complicating the problem is the need for a fast solution. Conventional binary arbiters (such as the arbiter illustrated in FIG. 1A) have a delay of about two gate delays in the uncontested case.
Hence, what is needed is an arbiter that makes routing decisions based on client requirements and/or preferences, and that operates with a similar number of gate delays.